Day 6：MCP 是什麼？Host / Client / Server 的三角關係

昨天我們已經讓模型成功呼叫工具。

流程其實不複雜：

模型決定要用工具
        ↓
程式執行工具
        ↓
把結果送回模型
        ↓
模型整理答案

既然 function calling 已經能做到這些事，那今天先回答一個問題：

為什麼我們還需要 MCP？

一、先從 N × M 問題開始

假設今天有一個 AI 開發工具，需要查 GitHub Issue。

我們可以自己寫一個 GitHub Tool，問題解決。

但接著另一個團隊也需要 GitHub，於是再寫一次。

Cursor、Claude Code、Zed 或其他 AI 工具，也都各自要接 GitHub、資料庫、檔案系統……

最後會變成：

M 個 AI 應用
×
N 個資料來源
=
M × N 份整合程式碼

每個應用都在重做差不多的事情。

軟體工程碰過很多次這類問題，常見的做法就是在中間加一層「共同標準」。

像 LSP 解決編輯器和程式語言之間的整合問題，MCP 想做的事情也很像：

AI Application
      ↓
     MCP
      ↓
Tools / Data / Services

把原本的 M × N，慢慢收斂成 M + N。

這也是為什麼 MCP 常被形容成：

AI 應用的 USB-C。

大家不用為每一種組合重新做一條線，只要講同一套協定就好。

二、Host、Client、Server 到底差在哪？

MCP 最容易搞混的就是這三個角色。

Host

Host 是使用者真正操作的應用程式。

例如：

Claude Code
AI IDE
自己寫的 Chatbot
Agent Application

Host 負責整個流程，包括：

• 呼叫 LLM
• 決定連哪些 MCP Server
• 管理工具
• 判斷 Tool Call 要不要真的執行
• 管理權限與使用者互動

所以真正「控制整場」的是 Host。

Client

Client 比較容易被名字騙到。

它不是「使用者的電腦」。

它是：

Host 裡面，專門負責和某一個 MCP Server 溝通的元件。

可以先想成：

Host
 ├─ Client A ── Server A
 ├─ Client B ── Server B
 └─ Client C ── Server C

Host 如果連三個 Server，內部就會建立對應的 Client 來管理連線。

Server

Server 則是負責把能力提供出去。

例如：

檔案系統
GitHub
Database
公司內部 API

Server 可以提供的能力包括後面會講到的：

Tools
Resources
Prompts

它本身不需要負責呼叫 LLM。

所以 MCP Server 也不代表一定需要 GPU。

三、Tool Call 放進 MCP 後發生了什麼？

昨天的 function calling 是：

LLM
 ↓
想呼叫 read_file
 ↓
我們自己的 Python 執行
 ↓
結果送回 LLM

放進 MCP 架構之後，大概會變成：

LLM
 ↓
Host
 ↓
MCP Client
 ↓
MCP Server
 ↓
真正執行 Tool

例如模型決定：

read_file("README.md")

Host 先收到這個決定。

接著可以先判斷：

這個 Tool 能不能執行？
這個 Server 有沒有權限？
要不要先問使用者？

確認之後，Client 才把請求送給 Server。

Server 執行完，再把結果一路送回 Host，最後交給模型整理。

所以 MCP 並不是把 function calling 換掉。

而是在 function calling 和真正的工具之間，加上一套標準化的連線方式。

四、Host 為什麼要放在中間？

這個位置其實很重要。

因為 Host 可以在：

模型想做事
        ↓
真正執行

中間插入控制。

例如：

限制只能讀某個資料夾
高風險操作先詢問使用者
記錄誰呼叫了什麼 Tool
直接拒絕不允許的操作

今天先知道 Host 有這個位置就好。

等到 Day 19、Day 20 講安全治理、最小權限和人工核准時，我們會再回來處理這一層。

五、連線後也不能馬上開始做事

MCP Client 連上 Server 之後，第一件事不是直接呼叫 Tool。

而是先進行初始化。

大概會經過：

Client
  ↓
initialize
  ↓
Server 回報版本與能力
  ↓
notifications/initialized
  ↓
正式開始工作

雙方會先確認：

協定版本
支援哪些能力
Server 能提供什麼

確認完成後，才開始進行後續操作。

這種做法跟 LSP 很像：先把彼此支援的能力講清楚，再開始合作。

六、實際上怎麼掛一個 MCP Server？

例如在 Claude Code 專案裡，可以透過 .mcp.json 設定 Server：

{
  "mcpServers": {
    "devbench": {
      "command": "uv",
      "args": [
        "run",
        "python",
        "days/day10_mcp_server/server.py"
      ]
    }
  }
}

Host 會依照這份設定啟動 Server。

如果使用 stdio 傳輸，大概就是：

Host
 ↓
啟動 MCP Server 子行程
 ↓
建立 Client
 ↓
stdin / stdout
 ↓
交換 MCP 訊息

至於這些訊息實際長什麼樣子，我們會留到 Day 8 自己手刻 JSON-RPC 時再拆。

Day 6 小結

今天最重要的其實不是背 MCP 名詞。

而是先搞懂這張圖：

            Host
             │
        ┌────┴────┐
        │         │
     Client     Client
        │         │
     Server     Server

三個角色可以先記成：

Host
→ 控制整個 AI 應用

Client
→ 負責跟某一個 Server 溝通

Server
→ 提供外部能力

而 MCP 解決的核心問題是：

讓不同 AI 應用，不需要各自重新整合每一個工具與資料來源。

它也沒有取代 function calling。

模型還是透過 function calling 決定「我要使用哪個 Tool」。

MCP 處理的是下一層：

Tool 從哪裡來？
怎麼描述？
怎麼連線？
怎麼呼叫？

明天：Day 7

下一篇：

MCP 三大原語 Tools、Resources、Prompts

三個看起來都像是在「把東西給模型」。

但真正的差別其實可以濃縮成一個問題：

誰控制它？

明天把這三個一次拆清楚。